其他
昨天 Kubernetes 弃用 Docker 刷屏,官方声明:不必惊慌
不必惊慌,实际上没多大影响。
以下是官方译文:
摘要:这里只是不建议将Docker作为底层运行时,你仍然可以使用专为Kubernetes创建的容器运行时接口(CRI)一如既往地在集群中运行Docker镜像。
对于Kubernetes最终用户,此次调整同样不会有太大影响。Docker不会就此消亡,你也仍然可以继续将Docker作为开发工具使用。Docker会继续构建起不计其数的容器,而运行docker build命令所生成的镜像仍可在Kubernetes集群内正常运行。
如果你使用的是GKE或者EKS等托管Kubernetes服务,则需要确保在未来的Kubernetes版本彻底去除Docker支持之前,为你的工作节点引入受支持的容器运行时。如果节点中包含自定义项,你可能需要根据当前环境及运行时要求做出更新。请与服务供应商合作,确保正确完成升级测试及规划。
如果你的集群一直在滚动扩展,则需要配合变量以避免服务中断。在1.20版本中,你将收到Docker弃用警告。而在未来的Kubernets版本(计划在2021年下半年发布的1.23版本)中,Docker运行时将被彻底移除、不再受到支持,届时您必须切换至其他兼容的容器运行时,例如containerd或者CRI-O。只需要保证你所选定的运行时,能够支持当前使用的Docker守护程序配置即可(例如日志记录)。
很明显,这里我们提到的“Docker”并不是同一种东西——它代表着一整套技术栈,而containerd高级容器运行时则是Docker中的一部分。Docker很酷、实用性极强,提供多种用户体验增强功能,让我们能够在开发过程中轻松完成协同交互。但是,用户体验增强功能对Kubernetes来说并非必需,因为Kubernetes并不是什么人类协作方。
结果就是,要想让containerd这个人类友好型抽象层发挥作用,Kubernetes集群就必须引入另一款名为Dockershimi的工具。但这款工具的介入又引发了新的问题,因为我们必须额外加以维护,否则就可能引发安全问题。事实上,Dockershim早在Kubelet 1.23版本时就已经被移除,或者说Kubelet很早就取消了将Docker作为容器运行时的功能。这时候很多朋友可能要问,既然Docker栈中已经包含containerd,Kubernetes为什么还要画蛇添足地搞出个Dockershim?
这是因为Docker与CRI(即容器运行时接口)并不相容。正是因为不相容,所以我们才需要Dockershim来缓冲一下。但这不是什么大问题,各位没必要惊慌——这件事的本质,就是把容器运行时从Docker转换为另一种受支持的选项。
这里需要注意的是:如果大家将底层Docker套接字(/var/run/docker.sock)设定为集群工作流中的一部分,那么转换至其他运行时会破坏掉当前业务的正常运行。这种模式称为Docker in Docker,好在我们可以使用多种选项解决这个特定用例,包括Kaniko、Img以及Buildah等等。
因此,虽然变化即将到来,虽然会给部分用户带来麻烦,但影响并不算大。而且从长远角度看,这其实是件好事。总而言之,希望大家放下抵触和恐慌情绪,坦然接受这个变化。
原文链接:https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
推荐阅读
转角遇到GitHub - 送给爱开源的你
Git · GitHub · GitLab · Gitee